PARAMETERIZED LOCK MANAGEMENT 
SYSTEM AND METHOD FOR 
CONDITIONAL CONFLICT 
SERIALIZABUJTY OF TRANSACTIONS 

The present invention relates generally to database man- 
agement systems and transaction processing systems that 
utilize a lock manager for protecting database resources 
from simultaneous incompatible uses, and more particularly 
to a lock manager that allows greater concurrent use of 
resources than the lock managers in traditional transaction 
processing systems while diminishing the "ACID" proper- 
ties of transactions only with respect to isolation between 
concurrent transactions. 

BACKGROUND OF THE INVENTION 

The present invention is directed at the management of 
transactions in database management systems so as to enable 
greater concurrency, and therefore more efficient transaction 
execution, than is allowed by DBMS's requiring strict 
adherence to the traditional "ACID" properties of transac- 
tions. More specifically, the present invention is directed at 
solving the "serializability" problems introduced by long 
lived transactions (LLPs). In addition to DBMS's and 
transaction processing monitors, the present invention may 
also be used in persistent programming languages as well as 
to concurrency control services for object resource broker- 
age systems. For simplicity, the present invention will be 
described with respect to DBMS's. 

The idea of revising or redefining the ACID properties of 
transactions to enable more efficient execution of transac- 
tions in systems that support LLPs is not new. However, the 
present invention provides a new methodology of "param- 
eterized lock management" that is relatively simple to 
implement and that allows applications to explicitly control 
the degree to which they can tolerate diminished isolation 
between concurrent transactions. 

THE TRADITIONAL TRANSACTION ACID 
PROPERTIES 

Traditional database management systems (DBMS's) 
were developed to support short, atomic transactions, such 
as for banking and airline reservation applications. Standard 
transaction management uses flat transactions that adhere to 
the ACID properties. ACID stands for Atomicity, 
Consistency, Isolation and Durability. 

Atomicity means that either the results of the transaction 
(Le., changes to the database) are all properly reflected in the 
database, or none of them are. Generally, a transaction is said 
to commit or abort When a transaction commits, all changes 
made to the database by the transaction are durably stored, 
leaving the database in a consistent state. When a transaction 
aborts, any changes made to the database by the transaction 
are backed out, once again leaving the database in a con- 
sistent state. 

Consistency means that each transaction commits only 
legal results to the database. Thus, a transaction must bring 
the database from one consistent state to another consistent 
state. 

Isolation means that the events within a transaction must 
be hidden from other transactions running concurrently. 
Concurrent transactions must not interfere with each other. 
They execute as if they bad the database to themselves. 

Durability means that once a transaction has been com- 
pleted and has committed its results to the database, the 
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system must guarantee that these results survive any subse- 
quent malfunctions. 
I The concept of atomicity for transactions is sometimes 
! overloaded with additional meaning. In particular, some- 
i 5 times atomicity is defined to mean "concurrency atomicity," 
i meaning that no transaction can observe any partial results 
' of an atomic transaction. This document and the present 
I invention, however, take the opposite approach. In 
particular, in this document atomicity is defined to mean that 
*° a transaction's commitment must be atomic. That is, once 
some work is committed to the DBMS (as opposed to 
committed to the parent of a subtransaction), the transaction 
in question cannot continue to perform work that may or 
may not be committed at some later point in time. This 
*5 notion of atomicity excludes such things as open nested 
transactions, but does not exclude partial rollbacks, the use 
of persistent savepoints, or other mechanisms that can be 
used by application programmers to control the behavior of 
the system's recovery mechanisms, since the final outcome 
20 of the transaction is still abort or commit. 

Failure atomicity implies that all effects of incomplete 
transactions must be undone in the case of failure. Failure 
atomicity may be undesirable for long lasting transactions 
(LLTs). For example, a designer who experiences a power 
25 failure just as he is about to commit a week's worth of work 
is unlikely to consider failure atomicity to be a valuable 
property of the design database. The obvious solution for 
this situation (as well as many other LLT's) is for LLT's to 
have persistent savepoints, which would make it possible to 
30 recover an incomplete transaction to the last savepoint taken 
before a crash. It is noted that removing failure atomicity 
does not require removing commitment atomicity. 

The atomicity and durability properties of transactions are 
35 required for system failure recovery, the isolation property is 
required for concurrency control, and the consistency prop- 
erty is needed for both failure recovery and concurrency 
control. 

It is well known that the ACID properties are well suited 
for virtually all kinds of short duration transactions. LLT's 
seem to be the only class of transactions where the ACID 
properties cause significant problems. LLTs can be complex 
queries that last for minutes or hours, data mining queries 
that last for hours or days, or concurrent engineering 

45 transactions, controlled by humans and lasting from minutes 
to months. Full application of the ACID properties in a 

j DBMS that supports LLT's can effectively prevent multiple 

| users from simultaneously using the system. Long term 
locking of system resources by an LIT can prevent other 

| SQ users or transactions from being able to perform useful 

| work. 

j It is a premise of the present invention that three of the 

\ ACID properties remain highly desirable for LLT's; 

| Keeping commitment atomicity for LLTs is universally 
55 acknowledged as being desirable. Just like short dura- 
tion transactions, LLT's should have only two possible 
outcomes: commit all work or abort all work (but see 
comments above regarding failure atomicity). 
Therefore, retaining commitment atomicity is desir- 

1 60 able* 

| Inconsistencies in a database are undesirable, although 
some kinds of inconsistencies may have to be tolerated 
j when dealing with LLTs. Maintaining consistency is 

j desirable, even for LLTs. 

65 Whether or jaot a transaction lasts a long time before it 
commits, durability for a committed transaction is 
i always desirable. 





It is a premise of the present invention that isolation is the 
only ACID property that it is desirable to compromise so as 
to reduce the impact of LLPs on system performance. More 
specifically, it would be desirable to compromise isolation in 
a controlled manner so as to give rise to as little inconsis- 5 
tency in the database as possible. 

It is a primary object of the present invention to provide 
a lock manager mechanism for providing applications the 
ability to explicitly control the extent to which concurrent 
transactions are isolated from each other or share data with 10 
each other. 



In summary, the present invention is a database manage- 
ment system (DBMS) that has been modified to provide 15 
improved concurrent usage of database objects, particularly 
when the system is executing long lived transactions. A 
subset of the transactions access database objects using 
parameterized read and parameterized write access modes. 
Each transaction using a parameterized write mode of access 20 
for a database object specifies a write access mode and a 
write access mode parameter, where the write access mode 
parameter indicates a reliability classification that indicates 
the reliability of the write locked data. Each transaction 
using a parameterized read mode of access for a database 25 
object specifies a read access mode, and a read access mode 
parameter, where the read access mode parameter indicates 
one or more reliability classifications that are acceptable to 
the transaction. Whenever a transaction requests access to a 
database object, the DBMS generates a corresponding lock 30 
request for the object. If the access request is a parameter- 
ized conditional access request, a corresponding parameter- 
ized lock request is generated. 

A lock manager processes each lock request by checking 
to see if any previously granted lock is conflicting or 
potentially conflicting with the requested lock. Two lock 
requests are unconditionally conflicting if their resource 
range overlaps and the access modes of the two requests are 
incompatible. Two requests are conditionally conflicting if 
analysis of their read/write parameters is necessary to deter- 
mine whether a conflict exists. If the lock request being 
processed is unconditionally conflicting with any 
outstanding, previously granted lock, the lock request is put 
on a queue of pending requests. If the lock request is not 
unconditionally conflicting with any outstanding, previously 45 
granted locks, but is conditionally conflicting with an 
outstanding, previously granted lock, the conditional con- 
flict is resolved by determining whether the write parameters 
for the write lock in question are a subset of the read 
parameters for the read lock in question. If so, then there is 
no conflict. If not, then the requested lock is in conflict with 
the outstanding previously granted lock. In none of the 
outstanding, previously granted locks is in conflict with the 
requested lock, the requested lock is granted. Otherwise it is 
put on a queue of pending lock requests. 55 

Every time a previously granted lock is released, any 
pending lock requests that overlap with the resource asso- 
ciated with the released lock are reevaluated. 



Additional objects and features of the invention will be 
more readily apparent from the following detailed descrip- 
tion and appended claims when taken in conjunction with 



FIG. 1 is a block diagram of a database management 
system implementing the present invention. 
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FIG. 2 depicts a set of lock management data structures 
for keeping track of granted and pending resource lock 
requests. 

FIG. 3 depicts an alternate set of lock management data 
5 structures for keeping track of granted and pending resource 
lock requests. 

FIG. 4 is a flow chart of the object locking method of the 
present invention. 

10 DESCRIPTION OF THE PREFERRED 

EMBODIMENTS 

Referring to FIG. 1, there is shown a database manage- 
ment system (DBMS) 100. Transaction operation and man- 
15 agement are handled by a transaction manager 102 and a 
lock manager 104, both of which are software procedures 
executed by the system's data processors) 106. The trans- 
action manager maintains a transaction table 108, sometimes 
implemented as a tree structure, for keeping track of the 
2Q identity and status of all pending transactions. The lock 
. manager 104 maintains a lock table 110, usually imple- 
mented using a hash table and various linked lists and/or tree 
structures (which will be discussed in more detail below). 
The lock table 110 keeps track of all locks that have been 
requested on resources in a database 112. The database 112 
stores all of the data that is accessible to transactions 
executed by the DBMS 100. 

The DBMS 100 will typically also include additional 
memory resources 114, one or more system busses 116 for 
30 interconnecting the various parts of the system, and a 
network interface 118 or other communications interface for 
handling communications with client workstations 120. 

"Conflicting transactions" are two or more transactions 
that access the same resource and at least one of them will, 
at least potentially, update the resource in question. Thus the 
results generated by at least one of the conflicting transac- 
tions may depend on the order in which the transactions are 
performed. 

A "data lock" is a mechanism for assigning a transaction 
certain rights to a database object, such as a table, a page, or 
a datum or record in a database table. Thus a first transaction 
may lock a particular object so as to ensure that no other 
transaction accesses the data in that data until the Erst 
transaction commits or aborts. The prior art includes many 
types of data locking mechanisms. 

"Overlapping resources" are database objects whose 
address range is the same or at least partially overlapping. 
An "access mode" refers to the way in which a transaction 
so or application accesses a data resource. The traditional 
access modes (browse, read, update, write and exclusive) are 
i described below. When using the parameterized read and 
! write access modes of the present invention, each unique 
| read access parameter value is associated with a distinct read 
j 55 access mode, and each unique write access parameter value 
is associated with a distinct write access mode. 

j Lock Table Data Structures Supporting 

| Parameterized Resource Access Requests and 

| ^ Access Modes 

j Referring to FIG. 2, the "lock table- 110 in a preferred 
■ embodiment is implemented as follows. A hash function 150 
is used to convert a resource identifier into a hash table 
address in a fixed size hash table 152. The resource identifier 
65 that is hashed hy function 150 may include a resource type 
or level indicator (e.g., indicating whether the resource to be 
. locked is a database, table, page or tuple) and the starting 



35 



45 



5 

address of the resource. Each addressable slot 154 of the 
hash table includes either a null value if there are no locked 
resources corresponding to that slot's hash table address, or 
a pointer to a list of lock control blocks (LCB's) 160 if there 
is at least one locked resource whose hash value corresponds 5 
to that slot's hash table address. 

The lock manager will allocate (i.e., generate and store) 
one lock control block (LCB) 160 for each lockable data 
item that is actually locked, and will allocate (i.e., generate 
and store) one lock request block (LRB) 162 for each lock 10 
held by a transaction. Thus, if a particular database object is 
locked by three different transactions at a given point in 
time, there will be one LCB 160 for that object and a linked 
list of three LRB's (one per transaction) "hanging" from that 
LCB. 15 
Each LCB 160 preferably includes: 
a lock ID 170, which will typically include a copy of the 

resource identifier for a locked resource; 
a mode indicator 171 indicating the most restrictive 20 
access mode (e.g., browse, read, parameterized read, 
write, parameterized write, or exclusive) of all the locks 
granted on the database resource represented by this 
LCB; 

a read parameters indicator 172, preferably in the form of 25 
a bitmap, representing the logical OR of the read 
parameters being used by the parameterized read locks 
(if any) outstanding on the locked resource; 
a write parameters indicator 173, preferably in the form of 
a bitmap, representing the write parameters of the 30 
parameterized write lock (if any) outstanding on the 
locked resource; 
a granted request list pointer 174 to a list of LRB's 162 for 
granted (i.e., currently outstanding) resource requests 
for the database resource represented by this LCB; 
a pending request list pointer 175 to a list (also called a 
queue) of LRB's 162 for pending (i.e., not yet granted) 
resource requests represented by this LCB; and 
a next LCB pointer 176 to the next LCB (if any) sharing 40 

the same hash address as this LCB. 
The read and write parameters represented by fields 172 
and 173 in LCB 160 represent an extension by the present 
invention to the conventional access modes used by 
DBMS's, and are discussed in more detail below. Each 45 
distinct value of a defined set of read/write parameter 
domain represents a corresponding data reliability classifi- 
cation or category. Thus a parameter domain having eight 
parameter values (each represented by a corresponding bit of 
an eight-bit parameter field) would allow for the definition 50 
of up to eight different data reliability classifications. In 
other embodiments of the present invention the parameters 
may be used to indicate properties of a database object other 
than "reliability,** such as the type or identity of the appli- 
cation which holds a write lock on the object, or other 55 
information that can be used by applications to determine if 
they are willing to read the data despite the presence of a 
write lock on it 

Each LRB 162, representing one granted or pending lock 
request, preferably includes: 

a mode indicator 181, indicating the access mode (e.g., 
browse, read, parameterized read, write, parameterized 
write, or exclusive) in which the resource is being 
accessed or being requested by a particular transaction; 
a transaction identifier 184, which identifies the tr ansae- 65 
tion that requested or holds the lock corresponding to 
this LRB; 



a parameters indicator 182, preferably in the form of a bit 
map, representing the read or write access mode param- 
eters (if any) being used by the owner of this read or 
write lock; this field is used only if the owner of this 
s lock or lock requested is using a parameterized access 
request; 

a lockset pointer 185 that is used to form a linked list of 
all the LRB's owned by transaction identified by the 
transaction ID 184; and 
10 a Next LRB pointer 186 to the next LRB (if any) for the 
same database resource as this LRB. 
Typical sizes for the read and write parameter fields in the 
LCB's and the access mode parameter field in the LRB's are 
one to two bytes, supporting eight to sixteen distinct param- 
15 eter values. 

FIG. 3 depicts an alternate data structure implementation 
110* of the lock table. In this implementation, the lock 
control blocks (LCB's) 190 each contains a granted request 
bitmap 194 and a pending request bitmap 195 in place of the 
20 granted and pending request list headers 174 and 175. Each 
of the request bitmaps preferably contains a bitmap of 
sufficient size (e.g., 64 or 128 bits) to represent the maxi- 
mum number of concurrent transactions supported by the 
system. Every active transaction is assigned to one of the 
25 bitmapped transaction identifiers. The granted request bit- 
map 194 contains a set bit for each active transaction that has 
been granted a lock on the resource represented by the LCB 
190. Similarly, the pending request bitmap 195 contains a set 
bit for each active transaction that has a pending lock request 
30 (also called an access request) on the resource represented 
by the LCB 190. 

The read and write parameter bitmaps 172 and 173, as in 
the FIG. 2 implementation, represent all the read and write 
parameterized access modes that have been granted on the 
35 database resource represented by the LCB 190. 

Whenever a lock request is granted, the read and write 
parameters in the LCB in question are efficiently updated by 
logically ANDing the read/write parameters of the granted 
lock request with the read/write parameter bitmaps previ- 
40 ously stored in the LCB. Ideally, when a lock is released, one 
would like the read and write parameters in the correspond- 
ing LCB to be immediately updated. However, this would 
require ORing the read parameters of all remaining read lock 
i holders (if a read lock is released) and ORing the write 
i 45 parameters of all remaining write lock holders (if a write 
lock is release). Since this would put an undue delay on 
transaction commit processing, in a preferred embodiment 
the lock is released without updating the read and write 
i parameter bitmaps in the LCB. If there are no more lock 
50 holders for the resource in question, the read and write 
parameter bit maps can be cleared, and if there are no 
( pending lock requests, then the LCB can be eliminated 
altogether. Otherwise, the read and write parameter bitmaps 
in the LCB are updated with respect to lock releases only 
' 55 when a potential read/write or write/read conflict is detected, 
in order to figure out whether to grant the requested lock. 
Alternately, LCB read/write parameter bitmap updating can 
be handled as a background task, similar to garbage collec- 
tion. 

60 

Serializable Transaction Histories 

j A transaction history is defined to be serializable if it is 
equivalent to a serial transaction history. This definition only 
makes sense if we also define what it means for two histories 
65 to be equivalent and what it means for a history to be serial. 
Equivalence can be defined in more than one way. Two 
histories are "conflict equivalent" if. 
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they contain the same transactions and the same opera- 
tions; and 

conflicting operations of non-aborted transactions are 
ordered the same way in both histories. 

Two operations are defined to conflict if they do not 5 
commute. That is, if the results of executing one before the 
other is in general not equivalent to executing them in the 
reverse order. It is common to model transactions as con- 
sisting of read and write operations only, and the conflict 
relation for those two operations is that two operations *o 
conflict if at least one of them is a write operation. The basic 
lock compatibility matrix is: 
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where "*" in Table 1 (as well as in the following tables) 
indicates non-conflicting operations. Table 1 indicates that 
two transactions can read the same data item, but a trans- 
action that is performing write operations must have exclu- 
sive access to it. ^ 

A transaction history H is serial if for every pair of 
transactions T f and T /9 either all operations of T, come before 
all operations of Ty in H, or all operations of Ty come before 
all operations of T £ in H. In other words, a transaction history 
is serial if it does not have any concurrency. Each transaction ^ 
executes to completion before the next one starts. If trans- 
actions are atomic, durable and consistent, then a serial 
transaction history will be correct. It follows that a concur- 
rent execution of transactions that is conflict equivalent to a 
serial one, must necessarily be correct, too. A transaction 3S 
history that is conflict equivalent to a serial history is called 
conflict serializable, and the corresponding correctness cri- 
terion is called conflict serializability. 

A serialization graph (SG) for a transaction history H is 
denoted SG(H). This is a directed graph whose nodes are the ^ 
committed transactions of H, and it has an edge between all 
pairs of nodes representing transactions that have issued 
conflicting operations. The direction of the edges are in 
accordance with the sequence of the conflicting operations. 
An edge from T, to Ty in SG(H) means that T, as issued an ^ 
operation that conflicts with and precedes some operation 
issued by Ty. Intuitively, if T £ and 1) are involved in a cycle 
in SG(H), then T, comes both before and after Ty in H, in 
which case H cannot be equivalent with any serial history. 
The fundamental theorem of serializability says that a his- 5Q 
tory H is serializable if and only if its serialization graph 
SG(H) is acyclic. 

To enforce serializability, virtually all commercial 
DBMS's use some form of data locking. Two phase locking 
(2PL) operates according to the following rules: 55 

1) a transaction may not perform an operation on a data 
item unless it holds a lock corresponding to the opera- 
tion (e.g., a read or write operation) in question on that 
data item; 

2) a lock request from a transaction must be delayed or 50 
rejected by the transaction scheduler if another trans- 
action holds a conflicting lock on the data item in 
question; and 

3) a transaction may not acquire a new lock if it has 
released any of its old ones. 65 

The first two rules prevent transactions from directly 
interfering with each other. The third rule, called the two 
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phase locking rule, prevents cycles in the serialization graph. 
The intuitive explanation of the two phase locking rule is as 
follows. When a transaction acquires a lock, that may 
establish an incoming edge to its node in the serialization 
5 graph. An outgoing edge from a transaction's node in the 
serialization graph can only be established if that transaction 
has released a lock. Thus, in order to create a cycle in the 
j serialization graph, some transaction must first release a lock 
| and then later acquire a lock. Since this is prohibited by the 
j 10 two phase locking rule, transaction schedulers that obey the 
t two phase locking rule ensure acyclicity of serialization 
j graph's, and therefore ensure serializable histories. 
. In addition to serializability, it is important for a transac- 
j tion management system to maintain a "strict" history by: 
as avoiding cascading aborts (ACA), in which the failure of 
j a first transaction causes other transactions that 

> depended on the results computed by the first tr ansae- 

: tion to abort; and 

ensuring that all data items written by a transaction T, 
20 cannot be overwritten by another transaction until after 
transaction T, has aborted or committed. 
The solution for maintaining a strict transaction history is 
to add the restriction that all write locks acquired by a 
transaction must be held until the transaction commits. A 
25 rigorous transaction history is maintained by requiring that 
all read and write locks acquired by a transaction be held 
until the transaction commits. With these added restrictions, 
two phase locking is called "strict two phase locking," or 
strict 2PL. 

30 A nasty problem with transaction schedulers that use the 
two phase locking rule is that transactions can get involved 
in deadlocks. As a consequence of the second locking rule, 
transactions sometimes have to wait for locks. Such waiting 
is caused by another transaction holding a conflicting lock, 

35 and the waiting transaction cannot make any progress until 
the other transaction releases its lock. If two transactions are 
waiting for each other, neither can make progress until the 
other one releases its lock. As long as neither of them 
releases its lock, the two transactions are deadlocked. More 

40 generally, deadlocks can involve more than two transactions 
that are waiting for each other in a cyclic way. 

Transaction Isolation Levels 
While isolation levels (i.e., levels of isolation between 
45 transactions) can be defined without reference to any par- 
! ticular implementation technique, the present invention 
| assumes the use of a lock manager for implementing isola- 
tion control. Isolation levels supported by commercial 
! systems, ordered from least to most restrictive, include: 
150 UR (uncommitted read). This is also known as read 
uncommitted, read through, or dirty read. This isolation 
I level allows an application to read both committed and 

: uncommitted data. As a result, the data read by an 

application (i.e., transaction) may be inconsistent with 
; 55 other data read by the application. Applications using 
■ the UR isolation level do not acquire any ordinary read 

locks, but will typically hold a browse lock at some 
high level in the resource hierarchy. Applications using 
the UR isolation level must still use write locks to 
; go pi Med write operations. There are two types of situa- 
tions where UR isolation is most typically used: 
(1) when the application does not need an exact answer, 
and (2) when the application (i.e., the person who wrote 
the application) knows that the data to be read is not 
i 65 being updated by anyone else. 

CR (committed read). This is also known as read com- 
mitted. The committed read isolation level allows an 
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application to read only committed data. CR isolation 
can be implemented using "zero duration" read locks. 
That is, if an application wants to read a database 
object, if suffices for the DBMS to check that a read 
lock could have been granted. If the read lock could 5 
have been granted, the object is read, but a read lock is 
not acquired. CR isolation is much less expensive than 
cursor stability (CS) isolation (described below) in 
terms of CPU cycles/Unless ah application needs the 
additional semantics offered by cursor stability isola- 
tion (and many applications do not), committed read 
isolation is the better alternative. 
CS (cursor stability). Cursor stability isolation allows an 
application to read only committed data and guarantees 
that a row will not change as long as a cursor is 
positioned to it CS isolation causes locks to be kept 15 
until the cursor moves to the next lockable object. For 
example, CS isolation is useful for an application that 
fetches a row from a database table (using a cursor to 
point to the row) and then performs a database manipu- 
lation based on the current row's data values before 20 
fetching another row. An application should have at 
least CS isolation for cursors that are to be used to point 
to rows of data that are to be updated or deleted by 
UPDATE or DELETE operations. 
RR (repeatable read). RR isolation allows an application 25 
to read only committed data and guarantees that read 
data will not change until the transaction terminates 
(i.e., a read that is repeated will return the original row, 
unchanged). RR isolation will not prevent the so-called 
phantom row phenomenon. That is, when a cursor is 30 
reopened, a row not present the previous time may 
appear. Read locks covering data items retrieved by an 
application using RR isolation must be kept until the 
transaction commits or aborts. 
TC (transaction consistency). TC isolation is also known 35 
as serializable isolation. TC isolation allows an appli- 
cation to read only committed data and guarantees that 
the transaction has a consistent view of the database, as 
if no other transactions were active. Transactions using 
TC isolation may be part of a transaction history that is 40 
not serializable where other transactions use lower 
levels of isolation. On the other hand, if all transactions 
in a history use TC isolation, that history will be 
serializable. All read locks acquired by a transaction 
using TC isolation must be kept until the transaction 45 
commits or aborts. 
Another isolation level is the QC (query consistency) 
level. QC isolation allows an application to read only 
committed data, and guarantees that all data accessed in a 
single query is consistent Implementing QC isolation by 50 
means of data locking is straightforward: all read locks must 
be kept until the query is completed (i.e., until the cursor is 
closed). Since cursors are defined using queries, QC isola- 
tion guarantees that all rows in a cursor's answer set are 
consistent. QC isolation is also valuable when performing 55 
statistical analysis, or when comparing or otherwise using 
together data values from different cursor row occurrences. 
QC isolation is weaker than RR isolation, but stronger than 
CS isolation. 

Isolation level CS, or weaker, is often not suitable for any 60 
query that uses aggregation and for any application that 
processes a cursor where the answer set must be consistent 
While using RR or TC isolation solves this problem, RR and 
TC actually provide more isolation than is needed for most 
such applications. The QC isolation level is the lowest 65 
isolation that provides the necessary and sufficient isolation 
for such queries. 
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Transaction Access Modes 

There are two basic access modes: read and write. When 
a database object is accessed in read mode, the agent in 
question can perform only read operations on that object. 
' Two or more transactions may access a given object 
concurrently, provided they all use read mode. When a 
database object is accessed in write mode, the transaction in 
question can perform both read and write operations on that 
object. More specifically, write mode enables reading, 

0 deleting, inserting and modifying objects. If an object is 
accessed in write mode by one transaction, no other trans- 
action can access that object in either read or write mode. In 
addition to these two basic access modes, many DBMS's 
support browse, upgrade and exclusive access modes. 

15 Browse mode enables a transaction to read an object even 
if some other transaction is currently accessing it in write 
mode. Thus, when using browse mode, transactions have no 
guarantee of a consistent view of the database, since there is 

20 a risk that they will read uncommitted data. The use of 
browse mode is often denoted as read through mode or dirty 
read mode, and is used with isolation level UR. Even an 
application using the UR isolation level needs to inform 
others of its presence, and it does so by accessing resources 
in browse mode. 

25 

Upgrade mode is similar to read mode, with the added 
semantics that the transaction in question may at any time 
request an upgrade to write mode. That is, it may upgrade its 
access mode. When a first transaction accesses an object in 

3Q upgrade mode, no other transaction can access the same 
object in write mode, or upgrade mode, until the first 
transaction commits or aborts. 

Support for upgrade mode was added to DBMS's to 
prevent single object deadlocks. Some applications work as 

35 follows: a number of database objects are "looked at," but 
only some of these are updated or deleted. If all the objects 
in question are "looked at," in write mode, the problem is 
unacceptably low concurrency. The alternative, assuming 
upgrade mode is not supported, is to "look at" objects in read 

40 mode and then promote from read to write mode whenever 
an update or delete operation is to be performed. The 
problem with this approach is that two transactions may 
access the same object in read mode, and if they both request 
promotion to write mode, the result is deadlock. This 

45 dilemma is eliminated by supporting upgrade mode, since 
upgrade modes are not mutually compatible. 

Exclusive mode is used by a transaction to prohibit any 

j other transactions from accessing the same object, irrespec- 

! tive of access mode. Exclusive mode is used when even 

j 50 browsers must be denied access to an object, such as when 

1 a table is to removed from a relational database. 

! The relationship between the five traditional access modes 
j is represented by Table 2, where B represents browse mode, 
R represents read mode, U represents upgrade mode, W 
! 55 represents write mode and X represents exclusive mode. 
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Asterisks (*) in Table 2 indicate compatibility. For 
example, read mode (R) access by a first transaction is 
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compatible with browse (B), read (R) or upgrade (U) mode 
in a second transaction. Write mode (W) is compatible only 
with browse mode. Exclusive mode (X) is not compatible 
with any other access mode. 

The five access modes are typically implemented using 5 
locks. It should be noted that it is usually necessary to 
support a number of different lock granularities. Typical lock 
granularities are tuple (i.e., database table row), object, page, 
table, class, file, tablespace, and database. Unless it is 
required that all transactions use the same lock granularity, 10 
the DBMS must be able to coordinate concurrent transac- 
tions that request locks at different levels in the resource 
hierarchy. The typical solution is once a transaction requests 
locks at some resource level, it will not request additional 
locks on lower levels of the same resource (because other 15 
concurrent transactions may acquire other locks on portions 
of that resource that are compatible with the first lock put on 
the resource), but it may request locks at higher levels. It is 
possible for a single transaction to use different lock granu- 
larities for different statements, but this is not significant for 20 
the discussion at hand. 

Hie following intent locks are needed: intent to request 
read (LR) locks indicate an intent to request read locks at 
some lower level, intent to request write (IW) locks indicate 
an intent to request write locks at some lower level, and 25 
RIW, which provides read access to the entire resource in 
question (e.g., a table) while also enabling the transaction to 
request update and write locks at some lower level (such as 
at the page or tuple level). It should be noted that an IW lock 
on a table enables its holder to request R. U and W locks (not 30 
just W locks) on tuples or pages with the table. An IW lock 
on a resource will be promoted to an RIW lock if the 
transaction holding the IW lock requests an R lock on the 
same resource. 

Two transactions with overlapping IW locks are consid- 35 
ered to be compatible because the potential conflicts will be 
resolved at some lower level in the resource hierarchy. For 
example, two transactions may need to update various tuples 
in a relational table. The both acquire IW locks on that table 
(and probably also on some higher level resources, such as 40 
file or tablespace, as well as the database), and then R, U or 
W locks on individual tuples. As long as the two transactions 
do not access the same tuple, then there will no conflict. 
Should they happen to access the same tuple, then there will 
be a conflict, and the possibility of deadlock cannot be 45 
completely excluded. However, the potential deadlocks 
caused by overlapping IW requests are, in general, no worse 
than the potential deadlocks associated with other resource 
locking situations. 

The complete lock (access mode) compatibility matrix is 50 
shown in Table 3. 

TABLE 3 

Compatibility Matrix for Access Modes 55 
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Note that the RIW row/column is identical to the inter- 
section of the R and IW rows/columns, In practice, browse 
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(B) locks and exclusive (X) locks are not used at the lowest 
resource levels. Using B locks at the lowest levels would, at 
least partially, defeat the purpose of using isolation level UR 
in the first place. For example, in a relational DBMS a 
transaction using the UR isolation level may request a 
browse lock at the table level (and all levels above the table 
level), and then proceed without requesting any locks on 
pages or tuples. Alternately, the transaction may request 
some sort of low-cost, short duration locks (known as 
10 latches) on pages or tuples to ensure atomicity of individual 
read operations. 

Conditional Conflict Serializability 

The present invention is based on the premise that seri- 
15 alizability is an unsuitable correctness criterion for some 
types of applications, such as concurrent engineering, typi- 
fied by CAD and CASE applications. The present invention 
uses a new correctness criterion, herein called conditional 
conflict serializability (CCSR) which is a weaker kind of 
20 serializability based on a weaker notion of conflict between 
transactions. 

The idea behind CCSR is to depart from a purely com- 
mutauvily based definition of conflict. While write opera- 
tions are still considered to be mutually conflicting, write- 

25 read and read -write conflicts are made conditional. This is 
achieved by using "parameterized" read and write modes, 
and corresponding parameterized read and write locks. 
If R(A) and W(B) denote parameterized read and write 

x modes, respectively, where A and B denote subsets of some 
parameter domain D, R(A) and W(B) are compatible if and 
only if B is a subset of A: BcA. For example, if the 
parameter domain D contains modes ul, u2 f through uS, 
R(ul, u2) is compatible with W(ul) because ul^j(ul, u2). 

35 Recall that two transaction histories are "conflict equiva- 
lent" if they contain the same transactions and operations, 
and conflicting operations of non-aborted transactions are 
ordered in the same way in both histories. Identical terms 
can be used to defined conditional conflict equivalence, so 

40 long as the parameter subset comparison is used to deter- 
mine which operations are conflicting. Thus, a transaction 
history is defined to be "conditional conflict serializable" if 
and only if it is conditional conflict equivalent to a serial 
I transaction history. 

[ 4s As discussed above, the serializability theorem states that 
a history H is serializable if and only if its serialization graph 
| is acyclic. A generalized version of this theorem applies to 
i CCSR. A conditional conflict serialization graph (CCSG) is 
I defined in the same way as a regular serialization graph, 
| so provided the term "conflicting operations" is understood to 
mean conditionally conflicting operations. Thus, a transac- 
tion history H is conditional conflict serializable (CCSR) if 
and only if the history's conditional conflict serialization 
graph (CCSG) is acyclic. 
55 The use of dirty reads does not provide a means for 
distinguishing between relatively stable database data and 
database data undergoing major changes. All sorts of incon- 
sistencies can result from dirty reads, and traditional 
DBMS's do not provide the user with any hints as to what 
60 they might be. On the other hand, the parameterized access 
modes of the present invention make it possible for database 
users (Le., typically, application programs) to receive infor- 
mation about the reliability of uncommitted data from the 
parameters the writer of the data has attached to the write 
: 65 lock on the data. More generally, the parameterized access 
) modes of the present invention (A) enables application 
programmers to customize the notion of conflict between 
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transactions, and (B) enables applications to communicate to 
each other the quality of uncommitted data. 

Hie parameter domain D can be user denned, or defined 
differently in different database systems. The "data model" 
used can be simple or complex, and thus the number of 5 
parameters in domain D can be small or large, depending on 
the needs of the application programs. 

Using the present invention, the standard assumption that 
read and write modes are mutually incompatible is reduced 
to a default, which transactions can override by proper use 10 
of parameters. Instead, applications or transactions can 
specify when reading and writing is incompatible. Using the 
example discussed above in which the parameter domain D 
contains modes ul, u2, through u5: 
R(ul, u2) and W(ul) are compatible, 
R(ul) and W(ul) are compatible, 
R(ul) and W(u2) are not compatible, and 
R(u2) and W(u2, u3) are not compatible. 
Non-parameterized read and write modes can still be 20 
denoted as R and W, but can be thought of as R(0) and W(+), 
where 0 denotes the empty set and * denotes an arbitrary 
superset of D. Thus, according to the rule that R(A) and 
W(B) are compatible if and only if Be: A. R(0) is incom- 
patible with all write modes and W(*) is incompatible with 25 
all read modes. Generally, there will be no such thing as a 
write mode that is compatible with every read mode, but 
R(D) denotes the read mode that is compatible with every 
write mode W(B) except W. 

When an application uses a parameterized write mode, it 30 
is indicating a willingness to share information with readers. 
That is, a transaction using parameterized writes indicates to 
other transactions the degree of safety associated with 
reading data that it has not yet committed. Analogously, the 
use of parameterized read modes by a transaction indicates 35 
willingness to read data that belongs to parameterized writ- 
ers. The new access mode compatibility matrix, using 
parameterized access modes, is shown in Table 4. In Table 
4, * indicates unconditional compatibility, blank table 
entries indicate unconditional incompatibility, and formulas 40 
such as B2crAl and Bl cr A2 indicate conditional compat- 
ibility. - 

TABLE 4 
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Parameterized lock modes increase the amount of memory 
used by the lock manager to record each lock, and also 60 
increase the amount of computation required to resolve lock 
requests. 

It may be noted that the present invention does not force 
users (i.e., applications) to quantify uncertainty, but rather 65 
allows them to classify iL That is, users can denote unreli- 
able data as belonging to one or more of a predefined set of 
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reliability categories. Each such category is represented by 
a reliability classification indicator, that is by a parameter in 
domain D. 

Especially for long lived transactions, it may be necessary 

5 to allow transactions to update the parameters associated 
with their write locks over time. For instance, the write 
locked data may initially be very unreliable (denoted by 
parameter ul), and then may be progressively upgraded to 
higher and higher levels of reliability (denoted by 
parameters, u2, u3, and so on) as the transaction progresses. 

10 Further, in systems having long lived transactions, there 
may be a need for lock management methods that do not 
simply block a transaction when incompatible lock modes 
are encountered. Rather, in at least some situations, param- 
eterized read modes may be treated as a request for data 

15 filtering, such that objects that are locked in incompatible 
write modes are skipped by parameterized reads. In some 
implementations of the present invention, applications using 
parameterized read access requests may include an addi- 
tional filter/wait flag to indicate if the read request is to be 

20 serviced by filtering out objects locked in incompatible write 
modes or is to wait for them to become available. 

The "uncommitted dependency problem," the "dirty read" 
problem and the "temporary update problem" are three 
names for the same thing: the use of uncommitted data is 

25 unreliable because it is subject to further change, due either 
to transaction abort or further modification by the applica- 
tion. Hie real problem is that an application can retrieve 
uncommitted data "assuming" that it is reliable, and then go 
ahead and do something based on this assumption. Contrary 

30 to this, the parameterized access mode method of the present 
invention explicitly informs applications when uncommitted 
data is encountered and also delivers information about the 
reliability of the uncommitted data. The application is free to 
handle such a situation in whatever way it sees fit: it may 

35 continuing as if nothing special happened, it may invoke 
some special procedure, it may perform a full or partial 
rollback, or do something else. Since no application will be 
deceived into believing that uncommitted data can be fully 
trusted, the uncommitted dependency problem is eliminated 

40 when using the present invention. 

The incorrect summary problem and the inconsistent 
analysis problem are two versions of another problem: an 



application may retrieve multiple data items and use them as 
input to some calculation, such as finding a sum or average, 
but interference from a concurrent transaction may cause the 
calculated value to be incorrect. This problem occurs when 
an updating application involves at least two data items: one 
that has already been retrieved by the analyzing application 
and one that has not yet been retrieved. One possible 
solution to this problem is to use an unparameterized read, 
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which is incompatible with all write modes. However, this 
solution is undesirable or impossible in some situations. 

Another possible solution, applicable only to special 
cases, is to establish a rule that all updates involving more 
than one data item should be performed using write mode 5 
parameters from a subset S of D. Any reader than needs to 
perform a consistent data analysis needs to avoid reading 
data that is write locked by any other transaction using a 
write mode parameter in subset S. 

Another possible solution related to access mode usage is 10 
to label data modification as minor, medium and major (or 
any other set of gradations). Thus a user would have objects 
locked in W(minor) mode most of the time, but would 
j upgrade to W(medium) or W(major) whenever more sig- 
nificant changes than usual are to be performed, such as is 
shu ffling the sequence of data items, deleting and inserting 
multiple data items, and so on. After the major changes have 
been made, the user would downgrade the write locks to 
W(minor). In this way, readers can protect themselves from 
reading data in the midst of undergoing major changes, 20 
while accepting smaller levels of data inconsistency. 

Handling Resource Access Requests 

Referring to FIG. 4, it can be assumed that in any system 
utilizing the present invention, a subset of the transactions 25 
access database objects using parameterized read and 
parameterized write access modes, while other transactions 
used unparameterized access requests. Each transaction 
using a parameterized write mode of access for a database 
object specifies a write access mode, and a write, access 30 
mode parameter, where the write access mode parameter 
indicates a reliability classification to other transactions that 
may request read access to the database object Each trans- 
action using a parameterized read mode of access for a 
database object specifies a read access mode, and a read 35 
access mode parameter, where the read access mode param- 
eter indicates one or more reliability classifications that are 
acceptable to the transaction. Whenever a transaction 
requests access to a specified database object, the DBMS 
generates a corresponding lock request for the object (step 40 
220). If the access request is a parameterized conditional 
access request, a corresponding parameterized lock request 
) is generated. 

1 The system's lock manager processes each lock request 
I by searching the lock table (steps 222, 224) for any corre- 45 
i sponding previously generated locks. Next, it checks to see 
; if any previously granted lock is conflicting or potentially 
i conflicting with the requested lock (steps 226, 230, 232). 
j Two lock requests are unconditionally conflicting if their 
I resource ranges overlap and the access modes of the two 50 
j requests are incompatible (step 226). For example, the blank 
positions in Table 4 represent unconditionally conflicting 
j access requests. In terms of the data structures shown in 
i FIGS. 2 and 3, the access mode of the current request is 
; compared with the most restrictive access mode previously 5s 
I granted for each of the overlapping resources for which any 
locks have been granted. For example, if the current access 
request is for an upgrade (U) mode or a write (W) mode, and 
there is already a granted lock for an overlapping resource 
that has a U or W mode, the current access request is 60 
unconditionally conflicting with the previously granted lock. 
If the lock request being processed is unconditionally con- 
flicting with any outstanding, previously granted lock (step 
226), the lock request is put on a queue of pending requests 
(step 228). 65 

Two requests are conditionally conflicting if analysis of 
their read/write parameters is necessary to determine 



